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(57) Abstract 

Apparatus and method for communication between an external system (104) and a communications apparatus (112). preferably 
embedded in a vehicle and including a modular base system (124) comprising a number of network devices (132) and a network management 
module (130). The network devices (132) include network modules (134) and network resources (138). Each network module (134) includes 
a number of subsystems that provide communications-related functions (188) and one or more of them is part of different network layers. 
The network modules (134) are able to communicate with each other using a common interface (142) under the management of the network 
management module (130). The network resources (138) include first in first out buffers, circular buffers and no copy buffers. The base 
modular system (124) communicates with an applications module (116) and physical devices (120) located in the vehicle. After network 
module registration with the network management module (130). communications can be made utilizing the modular base system (124) 
between the applications module (116) and the physical devices (120). 
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COMMUNICATIONS SYSTEM WITH MODULAR DEVICES 

FIELD OF THE INVENTION 
The present invention relates to system and method for 
5 communicating between an application program and a device 
through multiple communication layers and, in particular, 
for communicating using one or more selected network 
modules at the different coimnunication layers of the 
modular system. 

10 

BACKGROUND OF THE INVENTION 
Application programs are commonly involved with the 
transfers of information including data from/to a variety 
of devices including physical devices. Such information is 

15 typically used by the application program in conjunction 
with its processing'-related functions. The transfers of 
information can involve a number of different network, 
layers or levels- These network levels might include 
device drivers, device protocol drivers, routing protocols, 

20 transfer control protocols, sockets and other network 
links. It is commonplace to establish a communication path 
or channel using a particular defined set of network levels 
when transferring information between an application 
program and a device. That is, for a particular 

25 application and device, a single communication path or 
channel involving defined network levels is provided to 
handle desired information transfers. By way of example, 
for an Internet communication, network levels comprising an 
Ethernet device driver, an Ethernet protocol driver, TCP/IP 

30 {transmission control protocol/Internet protocol) and a 
socket interface can be operatively linked together. 

In a pending patent application assigned to the same 
assignee as the present invention, a portable mobile 
communications system is described that includes a 
35 communications apparatus that can be embedded in a vehicle 
for controlling information transfers between physical 
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programs. The base system provides the communications 
capability between the peripheral devices and the 
applications. Such communications include transfers of 
information including data between one or more of the 
5 peripheral devices and one or more of the applications. 
The base system is also involved with controlling and 
managing communications between the external system and the 
peripheral devices. Such communications can include the 
sending of information using results from running or 
10 executing an applications program, by means of data 
directly transmitted between the external system and one or 
more of the peripheral devices, and/or the downloading of 
applications programs. In one embodiment, the external 
system includes one or more remote stations that are 
15 located at a distance from the base system and one or more 
of the remote stations may utilize different communication 
protocols when accessing the base system. In such an 
embodiment, communications may occur wirelessly over an 
airlink to the base system, particularly where the base 
20 system is located at a great distance from the particular 
remote station. 

The modular base system includes a network management 
module and a number of network devices that are controlled 
and/or managed by the network management module. The 
25 network devices include network modules in which at least 
some of them can be properly linked together to establish 
a communication path or channel between an application and 
one or more peripheral devices, such as peripheral devices 
found in or associated with a vehicle. These network 
30 modules include a number of well-known communication 
devices, such as sockets, TCP/IP, device protocol modules 
including Ethernet and device drivers that support the 
particular peripheral or physical device. Such network 
modules also include an address resolution protocol (ARP) 
35 module (typically combined with a reverse address 
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registration effectively renders the base system 
transparent to the code employed by the user when accessing 
the base system. 

The common interface allows each network module to be 
5 connected to other network devices which implement and/or 
expect this interface. Each module implements a common 
interface of open, read, write, set options, get options 
and close functions or routines. Each such routine of each 
network module is provided to the network management module 
10 in connection with its management functions. 

The network devices of the base system also include a 
number of network resources that are created by one or more 
of the network modules to assist them in their 
communication tasks. These network resources include one 
15 or more FIFO (first in first out) buffers. A FIFO buffer 
is useful in establishing queues for task or network module 
management. The TCP (transmission control protocol) module 
may create a FIFO buffer in order to provide a resource 
that is useful in its responding to connection requests 
20 from one or more network modules in another layer, such as 
the socket interface module- Other network resources 
include circular buffers (CBsJ that have been determined to 
be flexible and effective in the organization and transfer 
of data within and between network modules. The IP 
25 (Internet protocol) module might utilize such a circular 
buffer to store route information related to one or more 
particular network devices that it commxinicates with. 
Still other network resources include one or more NCBs (no 
copy buffers) that are provided to reduce resource 
30 utilization and the need for copying data between network 
modules, which enhances throughput and responsiveness. In 
particular, the NCB can be passed bi-directionally between 
and among different network modules of the different 
layers . 
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(system network management protocol) functions. The 
security module is used in authenticating and/or approving 
network connections as part of a firewall protection 
scheme. The accounting module enables users to obtain 
5 information related to network or other usage costs when 
utilizing the modular base system 124 and can use such 
information to reconcile it with their own usage records. 

With regard to the operation of the modular base 
system, particularly involving the interactivity among and 
0 between network devices and the network management module, 
such operations or involvement can be categorized as 
involving registration of network modules, including 
resolutions of conflicts among network modules during the 
registration process and obtaining maximim transfer unit 
15 (MTU) information from network modules, together with 
creation of network resources and using them for 
information transfers. The registration of network modules 
with the network management module comprises the supplying 
of information by the registering network module to the 
20 network management module. This information includes: the 
protocol identification (ID) field, which refers to the 
assigned protocol numbers as provided in RFC (Request for 
Comments) 1700 ; the maximum transfer unit (MTU) field that 
represents the largest number of data, such as bytes, that 
25 the network module can send or receive; the network 
module's header information; and one or more of a number of 
routines for communication involving network modules, such 
as the open, close, read, write, set options and get 
options routines. The network management module returns a 
30 unique identification to the network module that the 
network module will use in its communications with the 
network management module. Additionally, the network 
management module will maintain a list of the particular 
network module's registration information that was 
35 supplied. The network management module will also keep a 
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manipulate options and close the opened interface with the 
second network module. Registered error handling routines 
can also be called by network modules when they experience 
errors during operation. A predetermined call function is 
5 utilized for invoking a particular or desired error 
handling routine. In response, the error handling routine 
takes appropriate steps in accordance with its algorithms 
or predetermined steps. Similarly, a network module, such 
as the IP module, may invoke a particular routing routine, 
10 in conjunction with or separate from, the execution of the 
error handling routine. In one embodiment, as part of a 
routing routine, a channel scheduling module is employed 
related to controlling or buffering information that is to 
be transferred at an appropriate or available time. 
15 Fundamental steps are also taken when there are 
communications involving network resources. In the context 
of the TCP (transmission control protocol) module, it is 
invoked, for example, when a first connection request is 
received, with this first connection request being queued 
20 in the FIFO buffer and indication is given thereof. When 
a second connection request, for example, is received from 
another network module, it is also queued in the FIFO 
buffer. Subsequent reads of the FIFO buffer result in the 
first connection request being read or accessed before the 
25 connection request that arrived second. A CB can be 
invoked for accessing route information stored in a 
predetermined location in the CB. The NCB is defined to 
include a total number of bytes. When conducting the 
allocating function, data to be transferred is copied into 
30 the NCB. The data occupies less than the total number of 
bytes. The NCB with the copied data bytes can then be 
passed from a first network module to a second network 
module. When the NCB is passed, a pointer is adjusted from 
a first pointer position to a second pointer position. The 
35 second pointer position relates to the header information 
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particularly when taken together with the accompanying 
drawings . 

BRIEF DESCRIPTION OF THE DRAWINGS 
5 Fig. 1 is a block diagram of the present invention 

illustrating major communication units; 

Fig. 2 diagrammatically illustrates the network 
management module, network modules and network resources of 
the modular base system, as well as utility routines and 
10 operating system construct; 

Figs. 3A-3B illustrate details of the network 
management module and representative network modules 
related to information lists, that are generated and stored 
using the network management module, having parameters 
15 useful in communication transfers and also illustrating 
representative network modiiles and their common interface; 

Fig. 4 diagrammatically illustrates the interaction 
between and among network devices and the network 
management module in connection with information transfers 
20 among network layers in the modular base system; and 

Figs. 5-9 constitute flow diagrams illustrating major 
steps that are conducted as part of information transfers 
among network devices of the network layers in conjunction 
with transferring information relative to one or more 
25 applications and one or more peripheral devices* 

DETAILED DESCRIPTION 
Referring to Fig. 1, a communications system 100 is 
illustrated, which includes an external system 104 and a 
30 communications apparatus 108, such as an embedded system, 
that communicate with each other using, preferably, a 
wireless communications system 112. In one embodiment, the 
embedded system 108 is embedded in a vehicle or other 
mobile unit to permit bi-directional communications from/to 
35 the vehicle. A disclosure directed to such an embedded 
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external system 104 when communication transfers are 
occurring in that direction. 

The embedded system 108 includes an applications 
module 116 having user programs with communication 
5 requirements relative to one or more sites different from 
the vehicle. That is, the external system 104 might 
require certain data or other information from the vehicle 
and one or more user programs function to provide such 
information. In that regard as well, the embedded system 
10 108 includes one or more devices 120 located in or 
associated with the vehicle including physical devices (all 
such devices referred to as "peripheral devices") . By way 
of examples, such peripheral devices 120 can include one or 
more of the following: GPS (global positioning system), 
15 dead reckoning sensors, facsimile machine, PDA (personal 
digital assistant), laptop computer, printer, display unit, 
modem, CD-ROM unit, storage device (s), medical condition 
sensor (s), vehicle condition sensors, vehicle cargo 
sensor (s), air bag sensor and general alarm sensors related 
20 to unlocking the vehicle or unwanted intrusion into the 
vehicle. In one embodiment, one or more such peripheral 
devices 120 may communicate with and be under the common 
control of a vehicle controller area network (CAN) as will 
be discussed later herein. 
25 The embedded system 108 also includes a modular base 

system 124 for use in providing information transfers 
between the applications module 116 and the peripheral 
devices 120. The modular base system 124 is modular in 
design so that the modular base system 124 can readily 
30 adapt to the addition of later designed communications- 
related modules that provide different and/or additional 
beneficial functions . E^urthermore, such modularity 
facilitates testing of units separately in the modular base 
system 124. The modular design also enables the user or 



wo 99/22301 



PCTAJS98/22598 



15 

module 142, especially where a particular application is 
not suitable for this socket interface. 

With reference to Figs. 2 and 3A-3B, more information 
and greater details are next provided related to the 
5 modular base system 124. As seen in Fig. 2, there are a 
number of network modules 134. All or a substantial number 
of them can be defined as being part of a particular one of 
a number of network layers. The network layers are defined 
similar to International Standards Organization (ISO) 
10 network layering, such as in accordance with the following: 

NFS/HTTP/FTP/TELNET/RLOGIN/USER Highest Network Layer 

TCP/UDP Modules i 

IP/ARP/RARP/ICMP/IGP/EGP/BGP 
Modules 

15 Device Protocol (Ethernet SLIP, ▼ 

PPP, 802) Modules Lowest Network Layer 

Device Driver Modules 

With regard to such network layers, it is anticipated 
that data/information cmpression is likely to occur at a 

20 number of the network layers, as well as in the 
applications. Such data compression will include the 
option to disable compression on lower network layers if 
such would impact higher-level applications. As an 
example, in the context of video data, under MPEG II, 

25 certain frames may not be suitable for compression, while 
streaming JPEG will be compressible again at a lower 

network layer. 

Each of such network modules 134 has a common 
interface associated with it that enables each of them to 

30 communicate in a common manner with other network modules 
134, on the same or different network layers. With regard 
generally to such network modxiles 134, each device driver 
module 146 supports the physical implementation of the one 
or more peripheral devices 120 that it is operatively 

35 connected to. A network layer above the network layer- 
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particular coicimunications channel is available for use; a 
communications channel scheduling module 188, which 
commonly works with the channel controller /monitor 18 6, and 
functions to retain or store information until a particular 
5 communications channel is available. Other support modules 
182 incliide: a data encryption module 190 for use in 
encrypting data before transmission, a data compression 
module 192 for preparing data in a reduced n-umber of bytes 
for transfer and a modem control module 194 that is 
10 available for assisting in modem transfers; a network time 
module 196 for providing necessary time-related information 
for routing functions and system network management 
protocol; a security module 198 for insuring only proper 
and authorized access to the modular base system 124; and 
15 an accounting module 202 involved with the tracking of 
usage of the modular base system 124, particularly in the 
context of making suitable information available that is 
useful to the user in connection with monitoring or 
maintaining network usage costs • 
20 Other network devices 132 having special functions for 

performing a particular task when certain or predetermined 
circumstances occur are defined generally as routines/ 
utilities 202 and include: error handling routine (s) 206 , 
information gathering routine (s) 208, routing routine (s) 
25 212, callback routine (s) 204 and checksum routine (s) 210. 
An error handling routine 206 is invoked when an error 
occurs, such as during the operation of a network module 
134 and which module wishes to report the error and have 
the error handled by this routine 206. The information 
30 gathering routine 208 provides statistics-related data 
concerning error reporting and/or other functions of 
network modules 134. A routing routine 212 is beneficial 
in ascertaining a suitable or optimum communications path 
or channel for a particular information transfer. In one 
35 embodiment, such a routing routine 200 includes the 
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coinmunications - The socket interface module 142 of the 
present invention is based on the known Berkeley style 
socket routines. In connection with coinmunications with 
network modules 134, the sockets of the socket interface 
5 module 142 rely on the coinmon interface routines of the 
network modules 134, particularly to gain port niambers used 
in lower network layer protocol communications. The 
sockets of the socket interface module 142 may directly 
manipulate port structures returned to it or such sockets 
10 may make TCP module 174 and UDP module 178 calls using the 
common interface routines of these network modules 134. 

The TCP module 174 is implemented or structured based 
on the standard RFC 793 including the specifications 
detailed therein. The TCP module 174 also has the common 
15 interface including access to routines useful with one or 
more sockets of the socket interface 142 for retrieving an 
instance of the TCP module 174. In conjunction with its 
operation, the TCP module 174 is invoked at initialization 
of the modular base system 124. The TCP module 174 is 
20 invoked after the IP module 154 is loaded and before 
implication of the services associated with the socket 
interface module 142. As applications use their instances 
of transmission control protocol, their state and current 
data values may change. To accommodate the multiple 
25 threads of execution, the TCP module 174 must be re- 
entrant. The TCP module 174 will use data blocks to hold 
application state/port information and associate the 
appropriate data block to the instance of the TCP module 
174. 

30 Similar to the TCP module 174, the UDP module 178 is 

based on previously established standards, namely, in RFC 
7 68 and the specifications detailed therein. In addition 
to having the common interface, the UDP module 178, as will 
be explained further herein, must provide and register its 

35 own open routine to allow sockets of the socket interface 
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each interface of the network module 134 that is 
registered. On the other hand, there are instances where 
an application wants to control information or data 
transfers, in the context of the routing that such 
5 information should take, and/or the physical media to be 
employed, for example. In that regard, security concerns 
may require a particular route for such an application and 
the modular base system 124 includes this capability for 
permitting such controls to be established by the user. 
10 When invoking the IP module 154, the length of the 

invocation might be so long that a configuration file may 
be necessary. The IP module 154 constructs a network 
device table based on the network devices 132 passed to it. 
Data associated with such network devices includes: the 
15 network device 132 name, the IP address, the network mask 
and the device type given with the name. Additionally, the 
data could include the network device's maximum transfer 
unit (MTU) related to the amount of data that the network 
device can handle and header length that relates to the 
20 amount of information comprising the header of the 
particular network device. The IP module 154 is able to 
call other protocol modules defined as being part of its 
network layer including the ARP/RARP, IGMP, BGP, EGP and 
IGP protocol functions when they are registered with the 
25 network management module 130. The IP module 154 reads and 
writes from a wrapper routine and such a routine will act 
as an insulator from the actual underlying physical 
read/write constraints. The IP module 154 implements 
blocking operations, for protocol to Internet protocol 
30 communications, using event constructs including events 
related to pending information receptions and pending 
information transmissions. 

The ARP/RARP (address resolution protocol/reverse 
address resolution protocol) module 158 provides the 
35 ability to decouple Internet protocol from the underlying 
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a PPP module 262, a DHCP (dynamic host control protocol 
module 264, an ATM (asynchronous transfer mode) module 266, 
a 802 module 2 68, and a CARP (controller address resolution 
protocol) module 270. Ethernet and Arcnet protocol modules 
5 250, 254 have well-established protocols, and their 
implementations as network modtiles correspond to such 
protocols. Like other network modules 134, each has a 
coitimon interface for proper communication with other of the 
network modules 134. The SLIP module 258 is based on 
10 standards set forth in RFC 1055 and protocol specifications 
detailed therein. The SLIP module 258 has the ability to 
provide the CSLIP functionality. The SLIP module 258 is 
able to operate in blocking and non-blocking modes, as well 
as operate in compressed or non- compressed modes. One form 
15 of invocation of the SLIP module 258 involves the use of 
command line argxaments that may be executed by currently 
available CPMW code. Such a command line argument would 
include the name imder which the SLIP module 258 registers 
itself. A second command line argument indicates the name 
20 of the network device 132 over which the SLIP module 258 
will read and write. Another optional coiratiand line 
argument specifies whether or not to use compression for 
the registered network device 132. The PPP module 262 is 
based on the standard RFC 1661 and the protocol 
25 specifications detailed therein. The PPP module 262 is 
responsive to dynamic Internet protocol assignment and 
dial-on-demand PPP operations. As with other network 
modules 134, the PPP module 266 registers itself with the 
network management module 130. The PPP module accepts a 
30 name over which to read and write and determines if the 
link is to be compressed. When dynamic IP addresses are 
provided, the PPP module 262 is given the IP address which 
it will assign or base assignments on. The DHCP (dynamic 
host control protocol) module 264 may be accessed and is 
35 useful in dynamically assigning IP addresses for 



wo 99/22301 



PCT/US98/22598 



25 

be used for communication purposes outside of the modular 
base system 124. 

With reference particularly to Figs. 3A~3B, further 
descriptions are provided regarding the registration of 
5 network modules 134 with the network management module 130, 
as well as establishing communication paths that involve 
the network modules 134 and network resources 138. Each 
network module 134 is required to register with the network 
management module 130. The network management module 130 
10 is able to monitor network resources 138 required at each 
network level, for each protocol of an associated network 
module 134 and dynamically resolve network module 134 
interface procedure calls. In one embodiment for 
registering with the network management module 130, a call 
15 identified as net_register is utilized and defined as: 
net_register (name, network layer, 
registration structure) . 
Each network module 134 sends the network management module 
130 a name to identify itself, particularly related to its 
20 protocol. The network management module 130 also requires 
the network module 134 to specify its network layer or 
level on which the particular network module 134 expects to 
operate. The network management module 130 additionally is 
useful in resolving inconsistencies or conflicts that might 
25 arise between or among network modules during the 
registration process. 

Each network module 134 also provides a set of values 
upon registration with the network management module 130, 
namely: 

30 protocolID - reflects the protocol's assigned 

number as set forth in the Internet publication 
"Assigned Numbers," RFC 1700; 

MTU (maximum transfer unit) ~ represents the 
largest number of bytes (octets) that the particular 

35 network module 134 can send or receive; 
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modular base system 124 to set network module specific 
options as detemined by the option code, option value 
(typically set or reset) and option value size (for 
determining data type and data space expected) . Get_option 
5 allows a user to verify currently set module specific 
options, with option settings being determined by the 
option code provided, returned in the option value space 
provided and is of the option value space size that is also 
provided. Close is used to remove the user initiating the 
10 close from the active users that the network module 134 is 
accommodating so that any space held by associated data 
structures are made available and so that a user is 
properly removed from conducting network module activities. 
Return codes indicate success or failure of each operation. 
15 ARG (argument) constitutes a value or other information 
determined by each network module 134 to help each such 
network module 134 identify the user and/or necessary 
values to carry out each operation. 

As depicted in Fig. 3, such information or values are 
20 stored in a linked list by the network management module 
130, together with additional items. In one embodiment, 
such registration information can be defined by the 
following linked list structure: 
guard; 
25 name; 

network layer; 
registration structure; 
node_next ; and 
node_prev. 

30 The information or values associated with name, 

network layer and registration structure data have already 
been described. The guard field is set to a unique value 
for validity checking. The node_next and node__prev fields 
are used to store pointers that relate to the elements 
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call, the calling network module 134 is able to make 
interface calls for the purposes of transferring data, 
manipulating options and closing the opened interface. The 
calling network module 134 uses an identifier returned from 
5 the net_open call when making any manipulation calls to the 
called network module 134. In one embodiment, the messages 
or calls that are invoked related to communication 
functions between two network modules 134 can be defined 
as: 

10 net_close (ID) ; 

net_write (ID, data, DataLan) ; 
net_read (ID, DATAP, DATAPLAN) ; 
net_set_option (ID, option, void optval, 
optvalsize) ; and 
15 net_get__option (ID, option, void optval, 

optvalsize) . 

Net_close calls the registered CloseRoutine associated 
with the ID field. The net_write calls the registered 
WriteRoutine associated with the ID field. The net_read 
20 calls the registered ReadRoutine associated with the ID 
field. The net_set_option calls the registered SetRoutine 
associated with the ID field. The net_get_option calls the 
registered GetRoutine associated with the ID field. 

With continued reference to Fig. 3A, the FIFO buffer 
25 216, the CB 220 and the NCB 224 of the network resources 
138 will be further described. Referring first to the FIFO 
buffer 216, it is useful in communications internal to as 
well as between network layers. The FIFO buffer 216 is 
accessible using the previously described OpenRoutine, 
30 CloseRoutine, SetRoutine, GetRoutine, WriteRoutine and 
ReadRoutine. Regarding the creation of a FIFO buffer 216, 
a network module 134 is typically involved and uses a 
predetermined function having a number of parameters, such 
as: 

35 net crt fif o (n_elts, name) 
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size; 

struct FIFOelt next; 
struct FIFOelt prev; 
data. 

5 The foregoing structure will be dynamically created to be 
the size of the buffer passed (as indicated by the buffer 
size argument given in the call), plus the size of the 
netFIFOelt structure • The buffer size will be stored in 
the size field. The buffer data will then be copied into 
10 the created netFIFOelt structure beginning at the data 
field. The structure will then be added to a doubly linked 
list using the next field to reference the next element in 
the list and the prev field to reference the previous 
element in the list. Netfifoelt structures are added to 
15 the list in a manner that the first element added is the 
first element retrieved. 

To cancel or otherwise remove the created FIFO buffer 
216, the user of the particular FIFO buffer 216 invokes a 
predetermined call, such as: 
20 net_destroy_FIFO (Id FIFO Id) 

Upon being invoked, this call will free memory allocated to 
each element stored in the queue of the particular FIFO 
buffer 216 being destroyed, as well as unregister itself 
from the network management module 130 and release any 
25 memory associated with the buffer control structure. 

Regarding the CB 220, it is useful in communications 
internal to as well as between network layers having 
different protocols. Like the FIFO buffer 216, the CB 220 
provides the OpenRoutine, CloseRoutine, SetRoutine, 
30 GetRoutine, WriteRoutine and ReadRoutine. A user of a CB 
220, such as a network module 134, creates the CB 220 
before it is used. In one embodiment, a function having 
parameters that is used to create a CB 220 is defined as: 
net crt circ (size, name) 
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options for faster circular buffer data access, e.g., to 
implement a linear hash buffer of elements • 

A previously created CB 220 can be removed by the user 
making a predetermined call such as through use of a 
5 net_destroy_circ routine identified as: 
net_destroy_circ (ID circid) 
The circid field is the identifier returned to the user 
from crt_crc or net_open. The functions resulting from the 
call to destroy_crc releases the memory held by the 
10 circjouf structure associated with the given circid • 

It should be appreciated that recovery or other 
procedures can be invoked when a particular FIFO buffer 216 
or CB 220 experiences an overflow or other buffer usage 
problem. In such a case, conventional and available 
15 techniques or procedures are included for access and usage 
in order to handle any such event or error that occurs. 

Referring to the NCB 224, such no copy buffers are 
intended to reduce the number of copy operations that occur 
when transferring data between and among network modules 
20 134. The network management module 130 has an established 
process for registered network modules 134 to allocate a 
NCB 224 by utilizing a predetermined function or call 
identified as: 

net_aloc (ID, size) 
25 The ID parameter represents the caller's network 
identification as returned by a call to net_register . The 
size parameter indicates the number of bytes the caller 
would like to allocate. Upon invoking the net_aloc 
function, a pointer is returned to a contiguous block of 
30 memory of the indicated size. Additionally, when calling 
the function net__aloc, the network management module 130 
determines the number of bytes that may prepend the NCB 224 
by taking into account previously stored information about 
the network module 134 that is making the call for the NCB 
35 224, with such information including the number of network 



wo 99/22301 



PCTAJS98/22598 



35 

To release memory allocated based on invocation of the 
net aloe function, a predetermined call to a routine for 
providing such a release is made by a network module 134, 
which call can be identified as: 
5 net_free (ID NCB) 

Invocation of the free function traverses the allocation 
linked list to find an entry containing the reference NCB. 
The given NCB is matched with a stored NCB by looking at 
10 the pointer values. The given NCB pointer value must be 
greater than or equal to the stored NCB pointer value and 
less than or equal to the stored NCB pointer value plus the 
stored NCB size (NCB size) • If a match is found, the 
stored NCB is freed as well as the entry containing the 
15 matched NCB. 

Further detail is next provided related to use of a 
NCB 224 in connection with passing or transferring data 
between and among network modules 134 including the 
prepending of header information. Such information is 
20 provided in the form of an example. Assume that the socket 
interfaqe module 142 requests 500 bytes. Upon such a 
request, 554 bytes are actually allocated. The network 
management module 130 obtains the header information for 
the network modules 134 that will follow the socket 
25 interface 142 in connection with the passing of the 500 
bytes of data. In that regard, the network management 
module 130 obtains the maximum header information 
(HeaderLen) for the TCP module 174 (assume 20 bytes); for 
the IP module 154 (assume 20 bytes) and for the Ethernet 
30 protocol module 250 (assume 14 bytes) . The particular 
socket of the socket interface module 142 receives a 
reference within the NCB 224 at an offset of 54 bytes so 
that only the 500 bytes requested may be directly accessed. 
The socket interface module 142 is used to copy the 500 
35 bytes into the NCB 224 and passes the NCB 224 to the TCP 
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the network management mod\ile 130 and called by the network 
modules 134 to process errors of the network modules 134. 
More than one error handling routine 206 can be 
registered. Each such error handling routine 206 might 
5 be called in the order in which it was registered or, 
alternatively, any such error handling routine 206 could be 
called or managed in accordance with other suitable rules 
or protocols. In one embodiment, an error handling routine 
194 can be registered by a user calling the following 
10 function having the identified parameters: 
ereg_hndlr (hndlr, ARG) 
A function pointer (hndlr) is given that represents the 
entry point to the particular error handling routine to be 
called for processing errors. The ARG parameter specifies 
15 information to be given as the first parameter to the 
called function or routine identified as hndlr. The error 
handling routine 206 also takes ID, error and char 
parameters in that order. The ID parameter identifies the 
network module 134 which generated the error. Typically, 
20 the error handling routine 206 calls get__option to get the 
protocol identifier and other information thereby 
identifying the caller. The error parameter identifies the 
error being reported. The char parameter constitutes the 
specific data for the generated error. The error handling 
25 routine 206 determines if the error is ' informational 
(statistic) or if it indicates a problem in the system. 
The return to a dreg__hndlr call provides a network 
identifier for the particular error handling routine 206. 
When a user determines that it wishes to discontinue 
30 using a particular error handling routine 206, a 
predetermined function is invoked, such as that identified 
by the following: 

eunreg_hndlr (ID) 
This called function removes the identified error handling 
35 routine 206 from the list of active error handling 
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system constructs. In particular. Fig. 4 illustrates a 
number of selected network modules 134 from different 
network layers that are involved in a particular 
application required by the applications module 116. Fig. 
5 5 briefly describes in flow diagram fashion the major steps 
involved in conducting such operations. In particular, the 
applications module 116 initially seeks to transfer data to 
at least one peripheral device 120. In accordance with 
this objective, the necessary or appropriate network 
10 modules 134 and network resources 138 must be registered 
and operatively opened or connected with and among each 
other before such a transfer can occur,- In that regard, at 
step 304 of Fig. 5, the Ethernet device driver module 280 
registers with the network management module 130. As part 
15 of its registration, the Ethernet device driver module 280 
registers the identity of its network layer, the size of 
its header information and its MTU, which indicates the 
maximum amount of data that can be transferred across its 
interface at one time. As previously described regarding 
20 Fig. 3, common interface routines are also registered and 
lists are stored related to information or values 
associated with the Ethernet device driver module 280. 

At step 304, the Ethernet protocol driver module 250 
acquires an interface for the Ethernet device driver module 
25 280 by use of the appropriately described functions or 
calls including use of an open call to be able to use an 
OpenRoutine for establishing the interface connection 
between these two modules. The Ethernet protocol module 
250 is also registered with the network management mod\ile 
30 130 and provides the same values, data and/or other 
information that is required for registration, just as was 
done when the Ethernet device driver module 280 was 
registered. Additionally, the Ethernet protocol module 250 
registers an eventl 214 with the Ethernet device driver 
35 module 280. This event will be utilized in connection with 
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and the calling of the open function that resulted in 
obtaining the OpenRoutine for the IP module 154 from the 
network management module 130. At step 348, the TCP module 
174 registers its name with the network management module 
5 130 and, like other network modules 130, specifies its 
network layer, header size and MTU, together with other 
required values or information to be included in the 
appropriately stored lists. A callbacks 204 is also 
registered by the TCP module 174 at step 352 with the IP 
10 module 154, This callbacks 204 is useful in transferring 
data from the IP module 154 to the TCP module 174. 

At step 356, the socket interface module 142 calls the 
registered TCP module 174 and its registered OpenRoutine. 
The socket interface module 142 specifies a passive call, 
15 which leads to the creation of a FIFO buffer 216 for 
another or returned TCP module interface that has a FIFO 
buffer 216 for use in accepting connections to be handled 
by the TCP module 174. Registration of TCP module routines 
(Read, Write, Get, Set, Close) is also made to enable their 
20 use by the socket interface module 142. This returned 
interface is used for reading and writing functions 
involving the sockets and the TCP module 174. At step 364, 
an event2 214 is registered with the TCP module 174 for 
indicating socket interface communications being received 
25 by it. 

With these network modules 134, network resources 138, 
callback routines 204 and event constructs 214 registered 
or otherwise established, an example related to transfer of 
data bytes is next described. Beginning at step 368 of 

30 Fig. 6, the applications module 116 seeks to transfer data 
bytes and starts this process by writing the data bytes 
over the socket interface module 142. At step 372 of Fig. 
7, in connection with use of a network resource 138 to 
transfer the data bytes, the socket interface module 142 

35 requests a NCB 224 with its size dependent on header sizes 
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applications module 116. At step 416 of Fig. 8, this data 
is received initially by the Ethernet device driver module 
280. The eventl 208 is set, at step 420, by the Ethernet 
device driver module 214 indicating that it has data 

5 available for transfer. Subsequently, at step 424, the 
Ethernet device driver module 280 sends the data bytes to 
the Ethernet protocol module 250 at step 424. Comparable 
to the description related to the transfer of data from the 
applications module 116, each network module 134 that is 

10 involved with the transfer of the data bytes adds its 
header to the NCB 224 and adjusts the offset pointer for 
access by the next network module 134 that will receive the 
passed NCB 224. In accordance with this procedure, at step 
428, the Ethernet protocol module 250 adjusts the offset 

15 pointer for the NCB 224 based on its header. Further, 
based on information that it receives, the NCB 224 is 
passed to the IP module 154 using callback2 204 and 
bypasses the ARP/RARP module 158. For a different 
destination, the Ethernet protocol module 250 accesses the 

20 callbackl 204 of the ARP/RARP module 158, which is provided 
to it in the packet of data being transferred. Once a 
resolution of where the data is to be transferred is 
complete, the ARP/RARP module 158 then sends the buffered 
data to that location. 

25 When the Ethernet protocol module 250 sends the data 

to the IP module 154, it adjusts the offset pointer of the 
NCB 224 based on its header at step 432. With regard to 
the transfer of the NCB 224, the IP module 154 invokes the 
callback3 204 routine that was registered previously by the 

30 TCP module 174, in accordance with step 436. The callback3 
facilitates the transfer of the data between these two 
network modules. Upon receipt of the transfer data, at 
step 440, the TCP module 174 adjusts the offset pointer of 
the NCB 224 based on its header information. At step 444, 

35 the TCP module 174 sets the event2 214 that was registered 
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In that regard, the channel controller/monitor module 186 
is used in monitoring and determining when the new 
communications channel is ready, in accordance with step 
484. With the new communications channel being ready for 
5 the data transfer, the channel scheduling module 18 6 
permits the data to be transmitted at step 488. Based on 
the release of the data using the channel scheduling module 
188, the IP module 154, at step 492, transmits the data 
over the new communications channel. Apparatus and 

10 methodology for providing such related error handling and 
routing functions is described in sxobstantially greater 
detail in a pending and related U.S. Patent Application 
identified by Serial No. 08/778,897 filed January 3, 1997 
and entitled ^^Communications Channel Selection". This 

15 pending application is hereby incorporated by reference, 
particularly including pages 11-34, as well as Figs. 1-5B., 
and even more particularly, pages 18-34 including the 
referenced drawing figures. Such disclosures in this 
related application have particular applicability to the 

20 present application in conjunction with its description of 
an embodiment for selecting an acceptable communications 
channel. In addition to the foregoing functions and 
operations for communication transfers involving the 
modular base system 124, further network modules can be 

25 designed and employed. Included among these might be a 
network, module 134 used to manage priority of 
communication transfers and provide preemptive control in 
connection with conununication transfers depending upon the 
presence of one or more predetermined factors. 

30 The foregoing discussion of the invention has been 

presented for purposes of illustration and description. 
Further, the description is not to limit the invention to 
the form disclosed herein. Consequently, variations and 
modifications commensurate with the above teachings within 

35 the skill and knowledge of the relevant art, are within the 
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What is cl; =^iined is: 

1. Ml apparatus for communicating using a plairality 
of modules, comprising: 

a plurality of network devices including a niomber of 
5 network modules and a number of network resources, with 
each of said network modules having a common interface; and 
a network management module communicating with each of 
said network modules for registering each of said network 
modules and for assisting said network modules in 
10 establishing said network resources that are useful in 
communication transfers involving said network modules. 

2. Z\n apparatus, as claimed in Claim 1, wherein: 

at least some of said network modules are defined as 
being included in different network layers and in which 
15 said some network modules in said different network layers 
communicate with each other using said common interfaces 
said network modules. 

3. An apparatus, as claimed in Claim 1, wherein: 
said network modules include a device driver module, 

20 a device protocol module, an Internet protocol (IP) module, 
a transmission control protocol (TCP) module that is 
separate from said IP module and a socket interface module. 

4. An apparatus, as claimed in Claim 3, wherein: 
said network modules include an address resolution 

25 protocol (ARP) module that is used in decoupling said IP 
module from one or more network modules that underlie said 
IP module in a different network layer. 

5. An apparatus, as claimed in Claim 3, wherein: 
said device protocol modules include one of an 

30 Ethernet module, a SLIP module and a PPP module. 

6. An apparatus, as claimed in Claim 3, wherein: 
said network modules include an ICMP module, an IGP 

module and an EGP module, each of which is defined to be on 
the same network layer as said IP module. 
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related to header information, module interface routines 
and module specific information in an argument field. 

14. An apparatus, as claimed in Claim 1, wherein: 
said network management module is used to store a 

5 list, by network layer, of header information of each of 
said registered network modules. 

15. A method for communicating using selected ones of 
a plurality of network modules and a network management 
module, comprising: 

10 establishing a network management module; 

providing a plurality of network modules including 
first and second network modules; 

registering each of said network modules with said 
network management module; and 
15 communicating information using selected network 

modules including between said first and second network 
modules utilizing a common interface associated with each 
of said first and second network modules. 

16. A method/ as claimed in Claim 15, wherein: 

20 said establishing step includes making available 

communication links between each of said network modules 
and said network management module and using communication 
messages having predetermined parameters as part of said 
registering step. 
25 17. A method, as claimed in Claim 15, wherein: 

said providing step includes maintaining communication 
separateness among said plurality of network modules which 
requires that each of said network modules be able to 
communicate with others of said network modules using said 
30 common interfaces. 

18. A method, as claimed in Claim 15, wherein: 
said registering step includes supplying information 
by said first network module to said network management 
module, with said information including a plurality of the 
35 following: a protocol assigned identification, header 
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25. A method, as claimed in Claim 22, wherein: 
said creating step includes transmitting a name for 
said CB and a mmber of bytes that said CB is allowed to 
hold as part of said parameter information. 
5 26. A method, as claimed in Claim 22, wherein: 

said creating step includes allocating said NOB by 
sending an allocate function to said network management 
module by said first network module and in which said 
allocate function has a number of parameters including an 
10 identification parameter that represents the identification 
of said first network module and a size parameter that 
relates to a number of buffer locations requested for 
allocation by said first network module. 

27. A method, as claimed in Claim 15, wherein: 
15 said communicating step includes said first network 

module opening an interface to said second network module 
and then using at least one of the following routines in 
connection with said communicating step: write, read, set 
options and get options. 
20 28. A method, as claimed in Claim 27, wherein: 

said communicating step includes closing said 
interface after said interface has been opened with said 
second network module by said first network module. 

29. A method, as claimed in Claim 15, wherein: 

25 said communicating step includes calling an error 

handling routine by said first network module using said 
network management module and in which said calling step 
includes identifying said first network module as 
generating an error and including a parameter that 

30 identifies the error being reported. 

30. A method, as claimed in Claim 15, wherein: 

said communicating step includes making a call to a 
callback routine for use in receiving data and in which 
said making step includes calling a set option routine of 
35 said second network module by said first network module. 



wo 99/22301 



1/10 



PCTAJS98/22598 




SUBSTITUTE SHEET-CRULE 26) 



wo 99^2301 



PCT/US98/22598 



2/10 




SUBSTITUTE SHEET (RULE 26) 



wo 99/22301 



PCTAJS98/22598 



3/10 



NETWORK MODULE I 



NETWORK MANAGEMENT MODULE 



GUARD 1 
NAMEi 

NETWORK LAYERi 
REGISTRATION STRUCTUREi 
PROTOCOL IDj 
MTUi 

HEADERLEN I 

OPEN ROUTINE] 

CLOSE ROUTINEi 

SETROUTINEi 

GETROUTINEi 

READROUTINEi 

WRITE RGUTINEj 

ARGUMENTi 

NODEJEXTi 

NODE_PREVi 



NETWORK MODULE n 

GUARD, 



'n 



NAME, 



n 



NODE PREV, 



n 



NETWORK UYER I 

NETWORK MODULEi -HEADERLENi 



NETWORK MODULE^ - HEADERLEN^ 



NETWORK LAYER n 



NETWORK MODULE2-HEADERLEN2 



NETWORK MODULEp-HEADERLENp 



NETWORK RESOURCES 



FIFO] 
IDi 

READPTRi 
WRITEPTRi 
NUMQDi 
BUFSIZEi 

FIFO„ ' 
IDn 

BUFSIZEp 



CBi 
IDi 

READPTRi 

BUFSIZEi 

BUFSTARTi 

CBn 
IDn ^ 

BUFSTARTn 



NCBi 
ID] 

REQUESTJIZEi 

WCBJIZEi 

CHARJCBi 

ALLOCPREVj 

ALLOC_NEXTi 

NCBn 
IDn 

ALLOCJEXTn 



FIG 3A 

SUBSTITUTE SHEET (RULE 26) 



wo 99/22301 PCT/US98/22598 



4/10 



^134 

; 

NETWORK MODULE 1 

(COMMON INTERFACE) 

OPEN CLOSE SET GET WRITE READ 



OPEN 


CLOSE SET GET WRITE 


READ 




(COMMON INTERFACE) 






NETWORK MODULE 1 





FIG. 3B 



SIBSIHUTE SHEET (RULE 26) 



PCTAJS98/22598 

5/10 



116" 
142- 




APPLICATIONS MODULE 



SOCKET mTCR FACEWODUlE 

]T3 



174 



TCP MODULE 



154- 



EVENT 2 



IP MODULE 



CB 



158 



-220 



CALLBACKS 



ARPAARP MODULE 



250- 



204s. 



ETHERNET PROTOCOL MODULE 



280- 



LI 



CALLBACK I 



CALLBACK 2 



204 



ETHERNH DEVICE DRie MODULE 

A 



EVENT 1 



PERIPHERAL OEVICE{S) 



120 



CALLED 
NETWORK 

DEVICES 



ERROR HANDLING ROUTINE 



CHANNEL SCHEDULING MODULE 



224 
NCB 



'214 



CHANNEL CONTROLLER/MONITOR MODULE 



ROUTING ROUTINE 



■204 



214 



_206 
-^188 
186 



212 



FIG. 4 

SUBSTITUTE SHEET (RULE 26) 



wo 99/22301 



PCTAJS98/22598 



6/10 
START ) 



ETHERNET DEVICE DRIVER MODULE REGISTERS ITS NAME WITH NETVlfORK 
MANAGEMENT MODULE INCLUDING SPECIFYING ITS NETWORK UYER, 
HEADER SIZE AND ITS MAXIMUM TRANSFER UNIT (MTU) 



ETHERNET PROTOCOL MODULE ACQUIRES AN INTERFACE FOR ETHERNET 
DEVICE DRIVER MODULE 



ETHERNET PROTOCOL MODULE REGISTERS ITS NAME WITH NETWORK 
MANAGEMENT MODULE SPECIFYING ITS NETWORK LAYER, HEADER SIZE AND 

MTU 



ETHERNET PROTOCOL MODULE REGISTERS EVENTl WITH ETHERNET DEVICE 

DRIVER MODULE 



ARP/RARP MODULE ACQUIRES TWO ETHERNET PROTOCOL DRIVER MODULE 

INTERFACES 



ARP/RARP MODULE REGISTERS ITS NAME WITH NETWORK MANAGEMENT 
MODULE SPECIFYING ZERO HEADER SIZE 



ARP/RARP MODULE REGISTERS CALLBACK 1 WITH ETHERNET PROTOCOL 
MODULE FOR ARP/RARP MODULE DATA ONLY 



CIRCULAR BUFFER (CB) CREATED BY IP MODULE 



-300 



304 



308 



312 



-316 



320 



324 



-328 



t 

SUBSTTTUTE SHEET (RULE 26) 



FIG. 5- 



wo 99/22301 



PCT/US98/22598 



7/10 



IP MODULE ACQUIRES AN INTERFACE FOR EACH OF ITS DEVICES 



IP MODULE REGISTERS 115 NAME WITH NETWORK MANAGEMENT MODULE 
SPECIFYING ITS NETWORK LAYER. HEADER SIZE AND MTU 



CALLBACK! REGISTERED BY IP MODULE WITH ETHERNET PROTOCOL 
MODULE THROUGH ARP/RARP MODULE 



TCP MODULE ACQUIRES INTERFACE FOR IP MODULE 



TCP MODULE REGISTERS ITS NAME WITH NETWORK MANAGEMENT 
MODULE SPECIFYING NETWORK LAYER, HEADER SIZE AND MTU 



CALLBACK3 REGISTERED BY TCP MODULE WITH IP MODULE 



SOCKET INTERFACE MODULE USES REGISTERED TCP MODULE TO CREATE TCP 
INTERFACE AFTER IT RECEIVES A CONNECT FROM APPLICATIONS MODULE 



TCP MODULE CREATES INTERFACE FOR READING/WRITING AND RETURNS 

CREATED INTERFACE FOR USE BY SOCKET INTERFACE MODULE AND 
APPLICATIONS MODULE, WITH RETURNED TCP MODULE INTERFACE HAVING 
A FIFO BUFFER FOR ACCEPTING CONNECTIONS 



-332 



■336 



340 



344 



-348 



352 



356 



r360 







EVENH REGISTERED BY SOCKET INTERFACE MODULE WITH TCP MODULE 






APPLICATIONS MODULE HAS DATAB 
DATA BYTES OVERSOi 


YTES TO BE TRANSFERRED AND WRITES 
:KET INTERFACE MODULE 



364 



368 



'SUBSTfTUTE Sheet (RULE 26) 



FIG. 6 



wo 99/22301 



PCT/US98/22598 



8/10 



SOCKET INTERFACE MODULE REQUESTS NCB (NO COPY BUFFER) WITH SIZE 
DEPENDENT ON HEADER SIZES FOR EACH NETWORK LAYER THAT FOLLOWS 



SOCKET INTERFACE MODULE COPIES DATA BYTES INTO NCB AND PASSES NCB 

TO TCP MODULE 



TCP MODULE ADJUSTS OFFSET POINTER FOR TCP MODULE HEADER AND 
ENTERS ITS HEADER INFORMATION 



TCP MODULE PASSES NCB TO IP MODULE 



IP MODULE ADJUSTS OFFSET POINTER FOR NCB BASED ON ITS HEADER AND 
ENTERS THE IP MODULE HEADER INFORMATION 



IP MODULE PASSES NCB THROUGH ARP/RARP MODULE 



ETHERNET PROTOCOL MODULE RECEIVES NCB AND ADJUSTS OFFSET 
POINTER FOR NCB USING ITS HEADER INFORMATION 



ETHERNET PROTOCOL MODULE TRANSMITS DATA BHES WITH HEADER 
INFORMATION OF ALL PRIOR NETWORK MODULES 



ETHERNET DEVICE DRIVER MODULE RECEIVES DATA BYTES PLUS HEADER 
INFORMATION OF HIGHER NETWORK LAYERS 



DATA FROM APPLICATIONS MODULE USED BY ONE OR 
MORE PERIPHERAL DEVICES 



DATA AVAILABLE FROM ONE OR MORE PERIPHERAL DEVICES FOR SENDING 
TO APPLICATIONS MODULE 



DATA RECEIVED BY ETHERNET DEVICE DRIVER MODULE FROM THE ONE OR 
MORE PERIPHERAL DEVICES 



■372 



376 



380 



384 



-388 



390 



■396 



-400 



■404 



•408 



12 



416 



.FIG. 7 



SUBSTITUTE SHEET (RULE 26) 



wo 99^2301 



PCTAJS98/22598 



9/10 



EVENTl SET BY ETHERNET DEVICE DRIVER MODULE 



420 



ETHERNET DEVICE DRIVER MODULE SENDS BYTES TO ETHERNET PROTOCOL 
MODULE WHICH READS DESTINATION INFORMATION 



ETHERNET PROTOCOL MODULE ADJUSTS OFFSET POINTER FOR NCB BASED 
ON ITS HEADER AND PASSES NCB TO IP MODULE USING CALLBACK! AND 
BYPASSES ARP/RARP MODULE 



IP MODULE ADJUSTS OFFSET POINTER OF NCB BASED ON ITS HEADER 
INFORMATION 



y-424 



428 



-432 



CALLBACK3 REGISTERED BY TCP MODULE CALLED BY IP MODULE 



TCP MODULE ADJUSTS OFFSET POINTER OF NCB BASED ON HEADER 
INFORMATION OF TCP MODULE 



■436 



■440 



TCP MODULE SETS EVENT 2 REGISTERED BY SOCKET INTERFACE MODULE 
INDICATING ITS RECEPTION OF DATA 



SOCKET INTERFACE MODULE RECEIVES DATA FROM TCP MODULE 



APPLICATIONS MODULE READS DATA RECEIVED THROUGH SOCKET 
INTERFACE MODULE FROM TCP MODULE 



WHEN AN ERROR OCCURS IN TCP MODULE RELATED TO DATA CORRUPTION 
TCP MODULE CALLS ERROR FUNOION 



INVOKED ERROR FUNCTION CALLS REGISTERED ERROR HANDLING ROUTINE 



444 



448 



-452 



-456 



460 



■f 

SUBSTITUTE SHEET (RULE 26) 



FIG. 8 



wo 99/22301 



PCTAJS98/22598 



10/10 



ERROR HANDLING ROUTINE SELECTS ANOTHER COMMUNICATIONS CHANNEL 
DUE TO UNSATISFACTORY PRESENTLY USED COMMUNICATIONS CHANNEL 



IP MODULE CALLS REGISTERED ROUTING ROUTINE 
— I 



ROUTING ROUTINE RETURNS NEW SELECTED COMMUNICATIONS CHANNEL 


^472 








CHANNEL SCHEDULING MODULE CALLED WHEN NEW COMMUNICATIONS 
CHANNEL IS NOT PRESENTLY READY 


.^476 








CHANNEL SCHEDULING MODULE BUFFERS DATA TO BETRANSMIHED UNTIL 
NEW COMMUNICATIONS CHANNEL IS READY 


^'^480 








CHANNEL CONTROLLER/MONITOR MODULE INDICATES THAT NEW 
COMMUNICATIONS CHANNEL IS READY 


^^484 








CHANNEL SCHEDULING MODULE PERMITS DATA TO BE TRANSMITTED 


,-488 








IP MODULE TRANSMITS DATA OVER NEW COMMUNICATIONS CHANNEL 


^^492 




u 



EHD ) 



FIG. 9 

SUBSTITUTE SHEET (RULE 26) 



IISTERNATIONAL SEARCH REPORT 



InternatioDai application No. 
PCT/US98/22598 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC(6) :GO<SF 13/00 

US CL : 709/200, 301 
According to Inteniational Patent Classification (IPC) or to both national classification and IPC 


B. FIELDS SEARCHED 


Minimnm documentation searched (classification system followed by classification symbols) 
U.S. : 709/200,223.227,230.231,301,302 


Documentation searched other than miniTmim documentation to the extent that such documents are included in the fields searched 
Microsoft Press Computer Dictionary, TCP/IP Illustrated. Volumes 1-2 


Electronic data base consulted during die international search (name of data base and, where practicable, search terms used) 
APS, WEST 

search terms: network management module, device driver. OSI, network layer, registration 


C DOCUMENTS CONSIDERED TO BE RELEVANT 


Category* 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No, 


Y 


UvS 5,636,371 A (YU) 03 June 1997, abstract, col. 9, line 23 - col. 
12, line 54 


1-34 


Y 


US 5,630,061 A (RICHTER et al.) 13 May 1997, abstract, col. 5, 
line 29 - col. 12, line 67 


1-34 


A 


WRIGHT, Gary R. et al., TCP/IP Illustrated Volume 2: The 
Implementation, Addison-Wesley Professional Computing Series, 
March 1996, pages 63-74, especially 65-66. 


1-34 


1 1 Further documents are listed in the cominualion of Box C 


1 1 See patent family ani»x. 




* Special categories of cited documonti: 

*A* dooumetit defkung the general state of the art which ii not considered 
to be of particular relevance 

'B* earlier document publbhed on or after the international filing date 

*L* document which may throw doubti on priority claim(s) or which is 
cited to establish the publication date of another citation or other 
special reason (as speoified) 

*0* document refeiring lo an oral disclosure, use, exhibition or other 
means 

*P* document published prior to the international filing date but later than 
the priority date claimed 


*T* later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 

'X* document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive step 
when the document is taken alone 

'Y* document of particulBT relevance; the claimed invention cannot be 
considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skiUed in the art 

*&* document member of the same patent family 


Date of the actual con^Ietion of the international search 
26 FEBRUARY 1999 


Date of mailing of the international search report 

12 MAR 1999 


Name and mailing address of the ISA/US 
Commissioner of Patents and Trademaiks 

Box per 

Washington, D,a 20231 
Facskoile No. (703) 305-3230 


Authorized officer 

ZARNI MAUNG O'^^C^ 

Telephone No. (703) 30^-6687^ 





Fonn PCT/ISA/210 (second sheet)(My 1992) ★ 



